Summary

After a 401 Unauthorized response, the Via rport/received parameters reveal the actual NAT-mapped source port, which may differ from the STUN-discovered port. The auth retry reused the original Contact with the stale port, causing registration to succeed but incoming requests to be routed to the wrong address.

• Rebuild Contact header from updated public_address after handle_client_authenticate, so the retry uses the server-observed NAT mapping
• Remove duplicate rport push in handle_client_authenticate — get_via already adds it, and duplicate Via params cause some servers to silently drop the request

Problem

1. Client discovers public_ip:60537 via STUN, sends REGISTER with Contact: <sip:user@public_ip:60537>
2. Server responds 401, Via header shows rport=16358;received=public_ip (actual source port differs from STUN)
3. public_address is updated to public_ip:16358, but the auth retry clones the original request, keeping the stale Contact public_ip:60537
4. Registration succeeds, but incoming INVITEs are routed to port 60537 instead of 16358

Fix

After handle_client_authenticate returns the auth response, check if public_address was updated and rebuild the Contact header with the corrected address before sending.

Test plan

• Existing tests pass
• Verified with live SIP registration behind NAT — Contact in auth retry matches rport from 401